Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities

ABSTRACT

In a communication between a mobile unit (UE) and a gateway general packet radio system (GGRS) support node (GGSN) wherein resource reservations setup protocol (RSVP) capabilities are shared by a session setup mechanism, preferably session initiation protocol (SIP) in which RSVP capabilities of the originating UE and GGSN are defined and exchanged. In addition, the SIP identifies the preferred RSVP mode of operation by negotiations. The SIP is utilized to indicate that: the UE is RSVP capable; those media flows which are based on RSVP; the preferred mode of operation i.e. either UE based RSVP signaling or GGSN proxy based RSVP signaling and to communication a final setup mode for RSVP signaling to the UE from policy control function (PCF). The SIP enables the UE and network to indicate intended quality of service (QoS) protocol during call setup. The SIP enables the terminating UE and/or network to indicate in their response the capability of supporting a particular QoS protocol, the call being rejected with a clear indication of cause when the terminating network is not capable of supporting the proposed QoS protocol. One of a plurality of SIP messages, such as OK and SIP  183  messages may be selected to respond to the originating UE.

This application is a continuation of U.S. Pat. application Ser. No.10/217,602, filed Aug. 13, 2002, which claims the benefit of priorityfrom U.S. provisional applications No. 60/312,918 filed Aug. 16, 2001and No. 60/312,920 filed Aug. 16, 2001, which are incorporated byreference as if fully set forth.

BACKGROUND

The present invention relates to communications between a mobile unitand a general packet radio service (GPRS) gateway support node (GGSN).More particularly, the present invention relates to the employment ofsession initiation protocol (SIP) for establishing the proper resourcereservation protocol RSVP capabilities and requirements as aprerequisite to establishing a communication using RSVP and furtherestablishing quality of service (QoS) capabilities of the UE and GGSN toinsure the desired quality of service (QoS).

Currently, the third generation partnership project protocol (3GPP)standards allow for the optional support of resource reservation setupprotocol (RSVP) in the user equipment (UE) and in the GGSN as signalingprotocol to ensure quality of service. Current standards provide aseparation between call setup procedures and establishment of QoS. Forexample, a UE having RSVP-capability may initiate a call (session) to anon-RSVP capable UE operating in a non-capable RSVP network. The lengthycall establishment procedures will successfully take place but withoutany indication of the intended protocol to be used for QoS. Uponestablishment of the call, the RSVP capable UE will start sending RSVPsignaling messages in order to reserve resources that are necessary tocarry the media stream along the route to the terminating end. TheseRSVP messages will be carried across the Internet, only to find anon-capable UE and a non-capable GGSN to complete the reservationprocedures. The lack of response from the terminating side to theoriginator of the RSVP signaling will result in expirations of theresources allocated to this particular media stream at both sides duringthe call establishment stage, resulting in a dropping of the session anda billing for service that could not have been offered. This inefficientuse of system resources reduces overall system capacity and efficiencydue to the fact that such a scenario would be persistent in call(session) setups between capable and non-capable RSVP networks and UEs.In addition, current technology provides optional support for resourcereservation protocol (RSVP) in both user equipment (UE) and universalmobile telecommunication services (UMTS) core network GGSN. As a result,neither the UE nor the GGSN can make any assumptions regarding thesupport of such protocol except that it is not applicable, i.e., NA is adefault mode of operation. It is therefore important to provide amechanism to enable an RSVP-capable UE and an RSVP-capable GGSN toinform one another of their RSVP capabilities before any communicationscan take place using RSVP.

SUMMARY

The present invention discloses a method by which RSVP capabilities of aUE and a GGSN are defined and exchanged. The invention provides amechanism by way of indications and responses to negotiate preferredRSVP mode of operation employing session initiation protocol (SIP).

The SIP is employed to indicate: the RSVP capability of the UE; thatmedia flow (those media flows) which is (are) based on RSVP; thepreferred mode of operation, i.e. either UE-based RSVP signaling or GGSNproxy-based RSVP signaling; and communication of the final setup modefor RSVP signaling to the UE from the policy control function (PCF).

In accordance with the present invention, the originating UE, duringsession setup, sends an SIP message to a proxy-call state controlfunction (P-CSCF) of a home network providing a list of all media types,capabilities and preferred mode of operation. The P-CSCF, which containsthe policy control function (PCF) is ultimately responsible forallocation of resources necessary to carry out the desired session. TheSIP information is utilized to make a final decision regarding the RSVPoperation. The P-CSCF (PCF) may request the RSVP capabilities of theGGSN, which capabilities may be stored within a suitable locale, andbased on capability information of the UE and GGSN, a final setupdecision is made. If both the UE and GGSN are RSVP capable, the P-CSCF(PCF) can decide the entity which will provide RSVP signaling. On theother hand, if the GGSN is not RSVP-capable or does not wish to supportan RSVP proxy operation, the decision to initiate RSVP signaling may bepassed to the UE. If the P-CSCF determines that GGSN shall provide theRSVP proxy, the P-CSCF advises the originating UE using SIP to stop RSVPsignaling. A decision is then passed to the GGSN using common openpolicy server (COPS) protocol to start RSVP operation.

The SIP is also utilized, further in accordance with the presentinvention, to provide an admission process employing the QoScapabilities of the communicating entities to determine the feasibilityof a successful outcome of a call/session setup procedure. Theoriginating UE/network indicates the intended QoS protocol during a callsetup procedure. In addition, a terminating UE/network when responding,will indicate, by way of the SIP, if it is capable of supporting aparticular QoS protocol. When not capable, the call will be rejectedwith a clear indication of the reason, which helps to reduce the cost ofcall setup, the number of messages over the network employed for QoSsignaling and the elimination of improper billing for services thatcould not be provided.

More efficient use of a call (session) procedure is accomplished byexchanging all available QoS capabilities during the call setup phasethereby eliminating a scenario where a call (session) is successfullyestablished between an RSVP capable UE/network and a non-capable networkincluding a UE which thereafter expires due to lack of response to theRSVP signaling messages from the non-capable terminating side.

Faster call (session) setup time is achieved by enabling the policycontrol function (PCF) at the terminating side to make an early decisionregarding the RSVP sender/receiver proxy function at the GGSN during thecall setup. The decision to instantiate the RSVP proxy function at theGGSN is made only after the call setup phase is successfully completedand during the RSVP signaling phase especially for the terminating sideof the session being initiated. The invention further minimizes, if noteliminates, unnecessary RSVP signaling over the network as well as theair interface thereby improving overall system performance and capacityand minimizing those cases where a user is billed for the resourcesallocated as a result of a successful session setup but in which asession is terminated without the services being performed.

BRIEF DESCRIPTION OF THE DRAWING(S)

The present invention and the objectives and advantages thereof will bebest understood from a consideration of the following figures whereinlike elements are designated by like numerals and wherein:

FIG. 1 is a simplified schematic diagram showing a network architectureand basic session establishment procedure employing SIP;

FIG. 2 shows a session establishment procedure for message exchange atthe originating UMTS architecture of the type shown in FIG. 1 whereinthe procedure is shown in greater detail;

FIG. 3 shows a session initiation protocol (SIP) invite message formatcurrently in use;

FIG. 4 shows a session description protocol (SDP) incorporating the UEcapability, the proxy configuration derived by the UE and the decisionregarding the configuration set-up by the P-CSCF (PCF) provided inaccordance with the present invention;

FIG. 5 shows a session initiation protocol (SIP) invite message formatconveyed from a UE to a P-CSCF and incorporating indications ofreservation protocol and preferred configuration, in accordance with thepresent invention;

FIG. 6 shows a session initiation protocol (SIP) 183 message format froma terminating UE to a P-CSCF of the terminating network andincorporating reservation protocol and preferred configuration, inaccordance with the present invention;

FIG. 7 shows a session initiation protocol (SIP) 183 message format froma P-CSCF of the originating network to a user equipment UE of theoriginating network and incorporating indications of reservationprotocol and preferred configuration in accordance with the presentinvention;

FIG. 8 is a session establishment procedure illustrating medianegotiation procedure performed during an initial session establishmentin accordance with current standards;

FIG. 9 shows a session establishment procedure similar to that shown inFIG. 8 and incorporating call/session establishment capabilitiesemploying SIP, in accordance with the present invention;

FIG. 10 shows a session description protocol (SDP) incorporatingreservation protocol capability and preferred configuration request anddecision, in accordance with the present invention;

FIG. 11 shows a SIP invite message format from UE (A) to P-CSCF (A) asshown in FIG. 8 and incorporating reservation protocol capability andpreferred configuration, in accordance with the present invention;

FIG. 12 shows a SIP invite message format from a P-CSCF (A) to an S-CSCF(A), shown, for example, in FIG. 8 and incorporating proposed QoSreservation protocol, in accordance with the present invention;

FIG. 13 shows a SIP 183 message format from a terminating UE (B) to aterminating P-CSCF (B) as shown in FIG. 8, in response to the invitefrom the originating UE (A), in accordance with the present inventionand wherein the UE (A) is RSVP capable;

FIG. 14 shows an SIP 183 message format from a terminating P-CSCF (B) toa terminating S-CSCF (B), shown in FIG. 8, wherein UE (B) is RSVPcapable;

FIG. 15 shows an SIP 183 message format from a terminating UE (B) to aterminating P-CSCF (B), shown in FIG. 8, and wherein UE (B) is not RSVPcapable and requests an RSVP proxy function;

FIG. 16 shows an SIP 183 message format from a terminating P-CSCF (B) toa terminating S-CSCF (B) in a direction toward the originating UE (A),as shown in FIG. 8, in accordance with the present invention and whereinUE (B) is not RSVP capable and the network acts as RSVP proxy;

FIG. 17 illustrates an SIP 823 message format from a terminating P-CSCF(B) to a terminating S-CSCF (B) toward the originating UE (A), as shownin FIG. 8, in accordance with the present invention and wherein neitherthe UE nor the network are RSVP capable;

FIG. 18 is an SIP 183 message format from the originating P-CSCF (A) tothe originating UE (A), as shown in FIG. 8, in accordance with thepresent invention and wherein both sides of the requested session cansupport RSVP and the GGSN proxy is installed; and

FIG. 19 shows an SIP 183 message from the originating P-CSCF (A) to theoriginating UE (A) in accordance with the present invention and for thecase where neither side supports RSVP and DiffServ protocol isacceptable.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

FIG. 1 shows a simplified overview of a session flow in a UMTS networkarchitecture. The network includes UE (A) and UE (B). UE (A) is locatedin a network A which includes GGSN (A) and P-CSCF (A), network A mayeither be the home network of UE (A) or be a network in which UE (A) isroaming.

UE (B) is located in a network B having a P-CSCF (B) and GGSN (B).Network B may either be the home network of UE (B) or a network in whichUE (B) is roaming. One or more other networks/CSCFs may exist betweennetworks A and B.

Operation of a UNITS Call/Session Setup Procedure is as follows:

Step S1. UE(A) starts a Session Initiation procedure to UE(B) thatincludes an SDP proposal.

The steps 2-4 are optional and may depend on terminal implementationsand/or terminal preconfigured settings. As a result, they are shown indotted fashion.

Step S2. The user at UE(B) is pre-alerted.

Step S3. An indication of the pre-alerting may be sent towards UE(A).

Step S4. User at UE(B) will then interact and express his/her wishesregarding the actual session.

Step S5. UE(B) generates an accepted SDP based on terminal settings,terminal pre-configured profiles and optionally the user's wishes.

Step S6. The accepted SDP is forwarded to the UE(A) in the payload of areliable SIP response.

Step S7. Initial bearer creation procedure is performed. During thisbearer creation step the resources in the UE(A)'s and UE(B)'s accessnetwork are reserved with PDP context procedures. Bearer resources inexternal networks may also be reserved at this point.

The steps 8-10 are also optional and may be skipped, and are shown indotted fashion.

Step S8. Terminal at UE(B) starts ringing.

Step S9. The alerting indication is sent towards the UE(A).

Step S10. User at UE(B) may interact and express his/her wishesregarding the actual session.

Step S11. UE(A) and UE(B) may perform bearer modification procedure atthis point, if the initial bearers reserved in step S7 and the wishes ofuser at UE(B) are different. During this bearer modification step theresources in the UE(A)'s and UE(B)'s access network may be modified bymodifying the PDP context, and the resource reservation in the externalnetwork may also be modified.

Step S12. Session initiation procedure is acknowledged.

FIG. 2 shows the session message exchange flow at the UMTS home networkarchitecture comprised of a UE, a P-CSCF and an S-CSCF and in accordancewith existing standards.

At step S1 the UE sends an SIP invite to the P-CSCF of the home network,which invite contains this session description protocol (SDP). P-CSCFexamines the invite messaging and forwards it to the S-CSCF, at step S2.S-CSCF of the home network examines the invite message and, at step S3,exerts service control, obtains the network operator serving the calledUE and then sends the invite message to the terminating network of thecalled UE or, alternatively, the network intervening between the homeand terminating network.

The home network S-CSCF, upon receipt of a session description protocol(SDP) from the terminating network, at step S5, relays this to the homenetwork P-CSCF, at step S6. The P-CSCF, at step S7 authorizes the QoSresources and thereafter, at step S8, relays the SDP to the home networkUE.

At step S9, the home network UE generates a final SDP message settingforth session, ID, version, session creator, destination address, realtime protocol (RTP) payload type, RTP format, clock rate and port,directed to the home network P-CSCF which, at step S10, relays the finalSDP to S-CSCF of the home network which in turn, at step S11, relays thefinal SDP to the terminating network or, in the alternative, the networkintervening between the home and terminating networks.

The UE, at step S12, creates a resource reservation which (moreinformation need here) resulting in relay of a success message from theUE to the P-CSCF of the home network at step S13, from the P-CSCF of thehome network to the S-CSCF of the home network, at step S14, and fromthe home network S-CSCF to the terminating network or in the alternativean intervening network, at step S15. Having established the resourcereservation, ringing from the terminating UE is subsequently relayed tothe S-CSCF of the home network at step S16 and relayed from the S-CSCFto the P-CSCF of the home network at step S17 and from the P-CSCF of thehome network to the UE of the home network at step S18.

Responsive to the ringing indication, the home network UE generates aring back at step S19 which indicates to the originating UE that thedestination is ringing.

The terminating network, in addition to relaying a ringing indicationultimately to the home network UE, generates, at S20, a 200 OKindication to S-CSCF of the home network, at step S21, which exertsservice control, required by session setup completion and, at step S22,relays the 200 OK message to P-CSCF of the home network which provides,at step S23 approval of the quality of service (QoS) commit and relaysthe 200 OK message to the home network UE, at step S24.

The home network UE, at step S25, initiates media flow, transmitting anacknowledge (ACK) to the P-CSCF of the home network, at step S26, theP-CSCF relaying the acknowledgement to the S-CSCF of the home network,at step S27, which, in turn, relays the acknowledge (ACK) to theterminating network or, in the alternative, to an intervening network,at step S28.

FIG. 3 shows an SIP message format which is defined in accordance withthe existing standards and as will be more fully described, lacksindications of reservation protocol and preferred configuration. The SIPmessage shown in FIG. 3 comprises a request and a response (first line),a message header (next fourteen (14) lines) and a message body(remaining lines 15-38).

FIG. 4 shows the additions to existing SIP messages provided inaccordance with the present invention. The proposed formats include theUE capability and proxy configuration heading at 10, the UE capabilityat 12, the proxy configuration 14 desired by the UE and the decisionregarding configuration setup by the P-CSCF (PCF), at 16. The use ofthese formats enables the UE to indicate to the P-CSCF (PCF) whether itis RSVP capable or not, shown at 14 and the preferred mode of operation,i.e., whether the RSVP sender/receiver proxy at the GGSN is preferred,shown at 16. The novel message format shown in FIG. 4 further enablesthe home network P-CSCF (PCF) to indicate the final setup to the UE bydirect decision, i.e. providing the UE with a message to stop RSVPsignaling which indicates that the RSVP proxy function is instantiatedat the GGSN or alternatively to continue RSVP signaling which indicatesthat no proxy is available. The novel message format shown in FIG. 4further enables the UE to indicate which flow is using RSVP versusdifferentiated services (DiffServ) protocol as shown at 18.

FIG. 5 shows an SIP invite message which incorporates all the additionalcapabilities of the present invention and wherein UE (A) indicates thatit is RSVP capable, shown at 19, and that a proxy operation ispreferred, shown at 20. The UE further indicates that the quality ofservice (QoS) for three different media flows I, II, III will be carriedusing RSVP protocol, shown respectively at 22, 24 and 26, while the QoSin last media flow IV will be carried by differentiated services(DiffServ), as shown at 28.

FIG. 6 shows an SIP 183 message which is the SDP message from theterminating UE shown, for example, at step S5 of FIG. 2 wherein theterminating UE (not shown) replies to the invite from the originating UEof FIG. 2 indicating to P-CSCF that it is RSVP capable, shown at 30, andthat RSVP proxy operation is not preferred, shown at 32. The terminatingUE further indicates that RSVP protocol will also be used for thesupport of media flow, shown at 34. These capabilities provided in theSIP are intended only for the serving network configuration use and hasno influence on other entities within the architecture. The P-CSCF maydelete the proxy configuration when the (PC=) section of the SIPmessage, shown at 30 and 32, before forwarding the message to the nexthop, i.e., the next router the message goes through.

FIG. 7 shows the SIP 183 message forwarded to the originating UE by thehome network P-CSCF, and indicating to the UE that the request for RSVPproxy function of GGSN is granted and that the originating UE shouldstop RSVP signaling, as shown at 36. This message could also be appliedto other SIP messages such as SIP 200 OK messages, among others. The SIP183 message of FIG. 7 further confirms that the media flow will becarried using RSVP protocol, as shown at 38.

As was set forth hereinabove, the present invention has the furthercapability of enabling the originating UE/network to indicate QoSprotocol during the call setup procedure. This technique furthermandates that the terminating UE/network indicates in a response whetherit is capable of supporting the particular QoS protocol. In a case wherethe terminating network is not capable of supporting the proposed QoSprotocol, the call is rejected with a clear indication of the causethereby: reducing the cost of call setup, reducing the number ofmessages over the network for QoS signaling and removing the possibilityof improper billing for services that cannot be provided.

By providing an existing UMTS call (session) setup mechanism, i.e. SIP,the originating UE is capable of indicating to the terminating UE thetype of protocol intended for QoS, for example, RSVP. The UMTS call(session) mechanism further enables the terminating UE to indicate tothe originating UE and the supporting (serving) network whether the typeof protocol proposed by the originating UE for QoS, for example, RSVP,is supported as well as being capable of indicating to the originatinguser and the serving network, the type of QoS protocol the terminatinguser can support for the proposed media type.

The UMTS call (session) setup mechanism, i.e., SIP by which theterminating network, i.e. P-CSCF/PCF has the capability of whether acall (session) setup can be continued or terminated based on thecapabilities returned by the terminating user (UE) and the networksupport of the GGSN RSVP Proxy function. The UMTS call (session), i.e.,SIP, enables the P-CSCF/PCF at the terminating network to indicate tothe originating network and user whether the network can support RSVPbased QoS. The UMTS call (session) setup mechanism, i.e., SIP, enablesthe P-CSCF/PCF at the terminating network to update the supported QoSprotocol indicated by the terminating UE, i.e., the ability to restorethe original proposed protocol by the originating UE as a result ofinstantiating the RSVP function. The UMTS call (session) setupmechanism, i.e., SIP, enables the GGSN RSVP sender/receiver proxyfunction to be instantiated during a call setup rather than during theQoS reservation phase.

The UMTS call (session) setup mechanism, i.e., SIP, enables theP-CSCF/PCF of the originating network to indicate to the originatinguser: whether the terminating network can support RSVP QoS; whether theRSVP proxy function is instantiated at the GGSN or RSVP based mediaflows, i.e. whether the UE should or stop continue sending RSVPsignaling messages. The UMTS call (session) setup mechanism, i.e., SIP,enables the originating UE to terminate the multimedia call/sessionsetup procedure based on the response received which advises as to thecapability of the terminating network to support QoS protocol. The UMTScall (session) setup mechanism, i.e., SIP, further enables theoriginating UE to continue the multimedia call/session setup procedureby adjusting the intended/proposed QoS protocol to support certain mediabased on the response received as to the capability of the terminatinguser.

FIG. 8, shows a communications system in which UE #1 is located within anetwork including P-CSCF #1 and S-CSCF #1, which network may be the homenetwork of the UE or a network in which UE #1 is roaming; and UE #2 in anetwork including CSCF #2 and P-CSCF #2, which network may either be thehome network for UE #2 or a network where UE #2 is roaming. In theembodiment shown in FIG. 2, it will be assumed that both the originatingand terminating UE are in their home network, for purposes ofsimplifying the description thereof, it being understood that the systemis basically the same except for the addition of ultimate transfer ofmessages through additional intervening networks.

In the example given, UE #1, at step S1, determines a complete set ofcodecs that UE #1 is capable of supporting for the session beingrequested. UE #1 builds a session description protocol (SDP) containingbandwidth requirements and characteristics of each media and assignslocal port numbers for each possible media flow. Multiple media flowsmay be proposed and for each media flow (M=line and SDP) there may bemultiple codec choices offered. At step S2, UE #1 sends the initialINVITE message to P-CSCF #1 containing the SDP built by UE #1. P-CSCF#1, at step S3, examines the media parameters and removes any choicesthat the network operator decides, based on local policy, not to allowon a network and, at step S4, forwards the INVITE message to S-CSCF #1.S-CSCF #1, at step S5, examines the media parameters and removes anychoices that the subscriber does not have authority to request, i.e.parameters of which the subscriber has not requested and paid for aspart of the services provided to the subscriber. S-CSCF #1 forwards theINVITE message to S-CSCF #2, at step S6 which, at step S7 reduces a setof supported codecs based on operator policy in a matter substantiallysimilar to step S5 performed by S-CSCF #1 and thereafter, at step S8forwards the INVITE message to P-CSCF #2, which, in a manner similar tostep S3 performed by P-CSCF #1, examines the media parameters andremoves any choices that the network operator will not allow on thenetwork, based on local policy, at step S9, and, at step S10, sends themessage to the terminating UE #2.

UE #2 compares the codecs that it is capable of supporting for therequested session and determines the intersection appearing in the SDPin the invite message. For each media flow that is not supported, UE #2and SDP enter media (m=line) with port=0. For each media flow that issupported, UE #2 inserts an SDP entry with an assigned port and with thecodecs in common with those from UE #1, these activities being performedat step S11. UE #2 returns the SDP listed common media flows and codecsto P-CSCF #2, at step S12.

P-CSCF #2, at step S13, authorizes a QoS resource system for theremaining media flows and codec choices for the common codecs for thesession and forwards this SDP to S-CSCF #2, at step S14. S-CSCF #2, atstep S15, forwards the SDP message to S-CSCF #1, which, at step S16,forwards the SDP message, to P-CSCF #1. P-CSCF #1, at step S17,authorizes the resources for common codecs for the session and, at stepS18, forwards the SDP to UE #1.

UE #1, at step S19 determines the initial codecs for this session andthe media flows which should be used for this session. If there was morethan one media flow or, there was more than one choice of codec for amedia flow, UE #1 includes an SDP and a “final SDP” message sent to UE#2 by UE #1, at step S20, this message being forwarded, as shown bysteps S21-S24.

UE#2 sends the “final SDP” message to UE #1 along a signaling pathestablished by the INVITE request, which signaling path has been omittedfor purposes of simplicity, it being understood that the signaling pathis in accordance with existing capabilities. The remainder of themulti-media session is completed in accordance with a single codecsession employing conventional means.

FIG. 4 shows a call (session) flow embodying the principles of thepresent invention and wherein like steps as between FIGS. 8 and 9 aredesignated by like numerals and wherein distinguishing steps aredesignated by a “prime.”

In the procedure shown in FIG. 9, UE #1 at step S1′, in addition todetermining the complete set of codecs capable of supporting therequested section and building an SDP in accordance with step S1 of FIG.8, UE #1 further determines a supporting QoS protocol, such as RSVP,DiffServ, . . . and so forth that UE #1 is capable of supporting forthis session, as shown at 42 of FIG. 10. As with the current method ofstep S1 shown in FIG. 8, the SDP is built containing bandwidthcharacteristics of each media flow as well as the assignment of localport numbers to each possible media flow. Multiple media flows maybeoffered as shown in the lines n=SDP, for example, in FIG. 11, whichshows two video media flows and two audio media flows at 44 and 46 atFIG. 11, as well as showing multiple calls. However it should be notedthat the two (2) audio media flows in FIG. 11 each have a different QoSprotocol, one being RSVP and one being DiffServ.

UE #1 sends the aforementioned SDP INVITE message to P-CSCF #1 at stepS2. P-CSCF #1, at step S3′, examines the media parameters and removesany choices that the network operators decide, based on local policy,not to allow on the network, as was the case with step S3, makingreference to FIG. 8. P-CSCF #1 further examines the RSVP capability ofUE #1 as well as its preference of the RSVP proxy operation. P-CSCF #1passes this information to policy control function (PCF) to request adecision regarding a network setup. P-CSCF #1 removes the (rc=) entry,shown at 48 in FIG. 11, this entry being omitted in the SDP shown inFIG. 12 and this SDP message (FIG. 12) is forwarded as the invitemessage to S-CSCF #1, as shown in step S4. S-CSCF #1, at step S5examines the media parameters and removes any choices the subscriberdoes not have authority to request, similar to step S5 in the embodimentshown in FIG. 8, whereupon S-CSCF #1 forwards the INVITE through the S-Ssession flow procedures, through S-CSCF #2, at step S6.

S-CSCF #2, similar to the current network technique shown in FIG. 8 atstep S7, examines the media parameters and removes any choices that thedestination describer does not have the authority to request andforwards the INVITE message, at step S8, to P-CSCF #2.

P-CSCF #2, at step S9′, performs all of the functions performed byP-CSCF #2 as shown in step S9 in FIG. 8 by examining the mediaparameters and removing any that the network operator decides, based onlocal policy, not to allow on the network. In addition thereto, P-CSCF#2 examines the QoS protocol offered in the SDP message prior to passingthe information to PCF for decision regarding the support of anyoptional functionality, such as the GGSN RSVP proxy function. This SDPINVITE message is then forwarded to UE #2, at step S10, also as shown inFIG. 12.

UE #2, at step S11′ determines a complete set of codecs, as well as thesupporting QoS protocols such as RSVP, DiffServ and so forth, that UE #2is capable of supporting for the session. Similar to step S11 in thecurrent technique shown in FIG. 8, UE #2 determines the intersectionwith those appearing in the SDP and the INVITE message. For each mediaflow that is not supported, UE #2 inserts an SDP entry for media, i.e.,n=line, with port=0. For each media flow that is supported, UE #2inserts an SDP entry with an assigned port and with the codecs which arein common with those in the SDP message from UE #1. These steps aresubstantially identical to the steps shown as S11 in FIG. 8. UE #2 isfurther able to indicate to P-CSCF #2 whether it is capable ofsupporting RSVP and whether the RSVP sender/receiver proxy function isthe preferred setting. UE #2 is also able to propose a different QoSprotocol in the event that the existing one is not supported, as isshown in FIGS. 13-15. More specifically, FIG. 13 shows a modified SIP183 message format from UE #2 to P-CSCF #2 in response to the INVITEfrom UE #1, the embodiment in FIG. 13 showing the case where UE #2 isRSVP capable, as shown at 50 in FIG. 13. FIG. 14 shows a modified SIP183 message format from P-CSCF #2 to S-CSCF #2 in the case where UE #2is RSVP capable. FIG. 15 shows a modified SIP 183 message format from UE#2 to P-CSCF #2 responsive to the INVITE from UE #1 and in the casewhere UE #2 is RSVP capable, as shown at 52 in FIG. 16.

UE #2 transfers the SDP listing, media flows and codecs to P-CSCF #2 asshown at step S12 in FIG. 12.

P-CSCF #2, at step S13′ authorizes the QoS resources for the remainingmedia flows and codec choices. P-CSCF #2 examines the RSVP capabilitiesof UE #2 and passes this information to PCF for a decision on both theRSVP proxy function and overall support for the proposed session. P-CSCF#2 may either reject the session, based on lack of support of theproposed QoS protocol, or allow the negotiations to continue by passingthe proposed changes to QoS protocol. As show at 52 in FIG. 16, in acase where UE #2 is RSVP capable, P-CSCF #2 determines the networkconfiguration and passes an indication to the originating network thatRSVP is supported. In a case where UE #2 is not RSVP capable and UE#2indicated it can support the proposed media type using different QoSprotocol, i.e. DiffServ, while the network can support RSVP proxyfunction, FIG. 11 showing an SIP 183 message format from UE #2 to P-CSCF#2 in a case where UE #2 is not RSVP capable and asks for RSVP proxyfunction, FIG. 12 showing an SIP 183 message format from P-CSCF #2 toS-CSCF #2 and directed toward UE #1 in a case where UE #2 is not RSVPcapable and the network is RSVP capable.

P-CSCF #2 is further able to instantiate the RSVP proxy function,restore the proposed QoS, for example, RSVP, and pass an indication tothe originating network that RSVP is supported. In an example where UE#2 and a serving network are not RSVP capable as shown at 54 in FIG. 13,P-CSCF #2 may choose to pass an indication to the originating side that:RSVP is not supported and maintain its current proposal by UE #2 tocarry the media type, to carry another QoS protocol; or simply rejectthe session based on operator policy. P-CSCF #2 forwards the SDPresponse to S-CSCF #2, at step S14. S-CSCF #2 forwards the SDP responseto S-CSCF #1 at step S15 and S-CSCF #1 forwards the SDP response toP-CSCF #1 at step S16.

P-CSCF #1, at step S17′, authorizes the QoS sources for the remainingmedia flows and codec choices and further examines RSVP capabilities ofthe terminating network and passes this information to UE #1 as shown inFIGS. 18 and 19. P-CSCF #1 is further capable of passing decisionsregarding GGSN RSVP proxy configuration, i.e., whether the RSVP proxyfunction is supported. In the case where the proxy operation issupported, the “stop RSVP signaling” message as shown at 56 in FIG. 18,is sent to UE #1 with the indication that RSVP is supported on the otherside, as shown at 58 in FIG. 18 by the message “RSVP capable”. In theevent that the RSVP proxy function is not supported, the message“continue RSVP signaling” is sent as an alternative, these alternativemessages respectively appearing at 56 and 58 in FIG. 18. If theterminating side does not support RSVP then the combination “not RSVPcapable” and “stop RSVP signaling” is sent to UE #1 not to use RSVP forthe proposed media stream and that the proxy function is not installed.In this case the alternative message “not RSVP capable” is inserted at58 in FIG. 18 in the example given.

P-CSCF #1, at step S18 forwards the SDP response from UE #2 to UE #1.

UE #1 determines which media flows should be used for this session andwhich codecs should be used for each of the media flows. If there ismore than one media flow, or if there is more than one choice of codecfor media flow then UE #1 must include an SDP in the “final SDP” messageor, alternatively, UE #1 may choose to terminate the sessionestablishment procedures if the media streams cannot be delivered usingthe proposed QoS protocols, which activities are performed at step S19′.

UE #1 sends the “final SDP message to UE #2 along the signaling pathestablished by the INVITE request as shown in steps S20-S24, which stepsare similar to steps S20-S24 in the current technique employed in thecall (session) flow shown in FIG. 8. The remainder of the multi-mediasession is completed in a matter identical to the single media/singlecodec session in the manner described hereinabove in connection with thecurrent method set forth in the description of FIG. 8. The modifiedsession description protocol for an SDP shown in FIG. 10 represents the“SDP” message sent from UE#1 to UE#2.

1. A method for establishing communication between a mobile unit (UE)and a network, which communication uses resource reservation protocol(RSVP), comprising: the UE: (a) sending a session initiation protocol(SIP) invite message incorporating: at least the RSVP capability of theUE and an intended quality of service (QoS) protocol; a proxy-call statecontrol function (P-CSCF) of the network, responsive to the invitemessage SIP: (b) making a decision as to whether the network or the UEshall initiate RSVP signaling; (c) selecting one of a plurality of SIPmessages for responding; and (d) communicating the decision of step (b)to the UE employing the selected SIP message.
 2. The method of claim 1wherein the selected SIP message is one of an OK message and anauthorize message.
 3. The method of claim 2 wherein the authorizemessage is an SIP 183 message.
 4. The method of claim 1, the P-CSCF, atstep (b), determining that the UE should not initiate RSVP signalingwhen the UE is not RSVP capable and the network is RSVP capable; and atstep (d), sending a message to the UE that it should not initiate RSVPsignaling.
 5. The method of claim 1, the P-CSCF, at step (b),determining that the UE should initiate RSVP signaling when the UE isRSVP capable and the network is RSVP capable; and at step (d), sending amessage to the UE that it should initiate RSVP signaling.
 6. The methodof claim 1, the P-CSCF, at step (b), determining that the UE should notinitiate RSVP signaling when both the UE and the network are RSVPcapable; and at step (d), sending a message to the UE that it should notinitiate RSVP signaling.
 7. The method of claim 1, the P-CSCF, at step(b), determining that the UE should initiate RSVP signaling when boththe UE and the network are RSVP capable; and at step (d), sending amessage to the UE that it should initiate RSVP signaling.
 8. The methodof claim 1, the P-CSCF, at step (b), obtaining an RSVP capability of thenetwork which is stored at a given locale.
 9. The method of claim 1wherein the QoS protocol comprises providing one RSVP and DiffServ. 10.Apparatus for establishing communication between a mobile unit (UE) andnetwork, which communication uses resource reservation protocol (RSVP)comprising: the UE having means for sending a session initiationprotocol (SIP) message incorporating: the RSVP capability of the UE; andan intended quality of service QoS protocol is one of RSVP anddifferentiated services (Diffserv). said network, including a proxy-callstate control function (P-CSCF) of the network, which, responsive to theSIP, makes a decision as to whether the network or the UE shall initiateRSVP signaling, and the network further including means for sending thedecision of the network to the UE.
 11. The apparatus of claim 10 whereinthe network, further includes means for determining that the UE shouldnot initiate RSVP signaling when the UE is not RSVP capable and thenetwork is RSVP capable; and the network further includes means forsending a message to the UE that it should not initiate RSVP signaling.12. The apparatus of claim 10 wherein the network, further includesmeans for determining that the UE should initiate RSVP signaling whenthe UE is RSVP capable and the network is RSVP capable; and the networkfurther includes means for sending a message to the UE that it shouldinitiate RSVP signaling.
 13. The apparatus of claim 10 wherein thenetwork, includes means for determining that the UE should not initiateRSVP signaling when both the UE and the network are RSVP capable; andthe network further includes means for sending a message to the UE thatit should not initiate RSVP signaling.
 14. The apparatus of claim 10wherein the network, includes means for determining that the UE shouldinitiate RSVP signaling when both the UE and the network are RSVPcapable; and the network further includes means for sending a message tothe UE that it should initiate RSVP signaling.
 15. The apparatus ofclaim 10 wherein the network further includes means for obtaining RSVPcapability of the network from a memory.
 16. The apparatus of claim 10wherein the network includes a general packet radio service (GPRS)gateway support mode (GGSN), said proxy-call state control functionobtaining the capability of said GGSN to assign initiation of RSVPsignaling.
 17. The apparatus of claim 10 wherein said means for sendingincludes means to request the UE to initiate RSVP signaling when thenetwork does not want to initiate RSVP signaling.
 18. The apparatus ofclaim 17 wherein said means for sending includes means for passing adecision to start RSVP operation to said GGSN using common open policyserver (COPS) protocol.
 19. A method utilizing quality of service (QoS)capabilities of communicating entities to determine feasibility of asuccessful call/session setup, comprising: a) one of an originating UEand network incorporating in a session initiation protocol (SIP) messagean intended QoS protocol as part of a call setup procedure including oneof resource protocol (RSVP) and differentiated services (DiffServ); b)one of a terminating UE and network selecting one of a plurality of SIPresponse messages for responding to the SIP message form the originatingUE when it is capable of supporting the intended QoS protocol; and c)rejecting the call when the terminating one of the UE-and network is notcapable.
 20. The method of claim 19 wherein step (c) further comprises:providing a message which is a clear indication of the reason forrejecting the call.
 21. The method of claim 19 wherein the selected SIPmessage is one of an OK message and an authorize message.
 22. The methodof claim 21 wherein the authorize message is an SIP 183 message.
 23. Amethod for facilitating call/session initiating setup time between ainitiating mobile unit (initiating UE) and a terminating mobile unit(terminating UE), each respectively associated with an initiating andterminating home network which may be one of the same network and adifferent network, comprising: the initiating UE transmitting a sessioninitiation protocol (SIP) message to the terminating UE whichincorporates a list of media to be transmitted, a preferred mode ofoperation, an RSVP capability and the ability of supporting a givenquality of service (QoS) capabilities including me one of RSVP and DiffServ; and a terminating network making a decision based only on the QoSprotocol regarding an RSVP proxy function.
 24. The method of claim 23wherein the terminating UE, responsive to a received SIP, sends aresponding SIP message to the initiating UE requesting an alternative toan RSVP capability.
 25. The method of claim 24 further comprising:sending a Diff Serv as an alternative to an RSVP capability.
 26. Themethod of claim 23 wherein the termination network selects one of aplurality of SIP messages for the responding SIP message.
 27. Apparatusutilizing quality of service (QoS) capabilities of communicatingentities to determine feasibility of a successful call/session setup,comprising: one of an originating UE and network having means forincorporating in a session initiation protocol (SIP) an intended QoSprotocol as part of a call setup procedure; one of a terminating UE andnetwork having means for responding to the SIP when it is capable ofsupporting the intended QoS; said responding means selecting one of aplurality of SIP messages for sending the response; and means forrejecting the call when the terminating UE/network is not capable. 28.The apparatus of claim 27 wherein said means for rejecting furthercomprises: means for providing a message which is a clear indication ofthe reason for rejecting the call.
 29. Apparatus for facilitatingcall/session initiating setup time between an initiating mobile unit(initiating UE) and a terminating mobile unit (terminating UE), eachrespectively associated with an initiating and terminating home networkwhich may be one of the same network and a different network,comprising: the initiating UE having means for transmitting a sessioninitiation protocol (SIP) message to the terminating UE whichincorporates: a list of media to be transmitted, a preferred mode ofoperation, an RSVP capability and the ability of supporting a givenquality of service (QoS) capabilities; and a terminating network havingmeans for making a decision regarding an RSVP proxy function means forselecting one of a plurality of SIP messages for responding to theinitiating UE and means for responding to the UE via the selected SIPmessage.
 30. The apparatus of claim 29 wherein the plurality of SIPmessages include at least an OK message and an authorize message. 31.The apparatus of claim 30 wherein the authorize message is an SIP 183message.
 32. The apparatus of claim 29 wherein the terminating UEincludes means responsive to a received SIP, for sending a SIP to theinitiating UE requesting an alternative to an RSVP capability.
 33. Theapparatus of claim 32 further comprising: means for sending a Diff Servas an alternative to an RSVP capability.